上篇提到監控指標與儀表板的常見服務們，有說到我們不會無時無刻看著儀表板

所以就需要自動化來幫助我們知道，監控中的指標有哪些緊急的狀態發生了

就來到了本篇的主題：警示與通知系統（Alert and notification system）

警示系統的兩大重點

會需要做警示系統的原因，除了自動化能減少看儀表板的人力之外

也可以設定警示系統只跳出緊急且重要的事件，以達到快速且即時反應的效果。

而Alert的設定包含兩大重點：

針對監控指標的警示條件(Metrics Threshold/Condition)

舉個例子，如果過去24小時內你的伺服器CPU平均使用量從30%變成80%

這個時候主機服務可能還不會停止運作，但你會不會需要知道發生了什麼事？

所以如果我們有一個折線圖去紀錄平均CPU使用量，

當CPU這個監控指標超過60%的時候跳Warning，高於80%就跳Critical等等

而60%跟80%這個監控指標的門檻，就是我們需要自己定義並設定在警示系統的數值

上面這種是一次性的門檻，而在軟體運行上我們常會觀察一段時間內持續增減的資料趨勢

所以另一種設定方法也很常用就是：一段時間內無法執行某些動作時，就跳警示。

舉個例子，如果你的服務是個入口網站，正常來說，使用者都要能連到你的網站

如果一個持續跑著的API自動化測試，在10分鐘內，沒辦法拿到正常的200 OK code

也可以設定成類似SLA的監控警示條件，並確保不會有長時間服務中斷的情況發生。

這類跟商業邏輯相關的服務監控警示，也會被稱為是P0 Criteria（最高優先度標準）

警示後需要做的實際行動(Action Required)

收到警示後，也可以分為兩種類型：

不需要人為介入處理 (No Action)

這類警示通常可能不屬於會影響產品狀態的事件，可能是警示但不到錯誤的階段

或是初期還在測試監控指標需要設定在多少門檻值的警示。

一般來說，最好的做法是把這些不需要人為處理的警示刪減得越少越好

不然很容易造成維運團隊會有警報疲勞(Alert Fatigue)的現象產生

就像你每天都收到一堆被標示成很重要的郵件，但其實並不是每件事都這麼重要

要把每日對事件的專注力，放在真的重要且需要處理的事項上。

需要人為介入處理 (Action Required)

這類需要人為處理的警示，才是軟體維運團隊比較需要在意的。

像是以SaaS軟體產品為例，你今天上一版新的Hotfix到Production環境上之後

效能指標如果出警示，你就知道新版可能有造成效能上的影響，團隊就能即時反應

QA可以開始看遙測資料的細節，試著提出假設並重現問題

RD也可以針對新版有修改的Code去縮小可能發生問題的程式碼修改

整個開發團隊不需要依賴客戶回報問題來改善產品，而是用監控系統來做到：

「從被動(Reactive)回報去處理問題，到主動(Proactive)發現並解決問題。」

通知系統

最後提一個維運團隊也很常用的通知系統 (Notification)

其實通知就是在監控系統的最後端，把警示推送給可以解決問題的維運團隊成員XD

像是一直以來都很受歡迎的Slack，有App也有網頁版，也有API可以串接各種服務

或是靠著微軟生態系慢慢打市占率的Teams也都有很類似的串接功能

比較早期大家會用寄Email的方式做警示的通知，但就像上面提到的警示疲勞，

你可能一天有超級多的郵件要處理，每天收到太多就不會想去處理，反而效果不好。

有了警示系統之後呢？

警示系統幫助我們能夠把重要的狀態自動化，出問題的時候能即時示警

當這些設定的警示響了之後，QA還是會回到老本行做一件事：重現問題。

那我們可以怎麼利用遙測資料來抽絲剝繭來找到問題呢？

下篇來介紹赫赫有名的ELK(Elasticsearch，Logstash，Kibana)